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Abstract. In this work, we present asynchronous multi-context sys¬ 
tems (aMCSs), which provide a framework for loosely coupling dif¬ 
ferent knowledge representation formalisms that allows for online 
reasoning in a dynamic environment. Systems of this kind may inter¬ 
act with the outside world via input and output streams and may there¬ 
fore react to a continuous flow of external information. In contrast to 
recent proposals, contexts in an aMCS communicate with each other 
in an asynchronous way which fits the needs of many application 
domains and is beneficial for scalability. The federal semantics of 
aMCSs renders our framework an integration approach rather than 
a knowledge representation formalism itself. We illustrate the intro¬ 
duced concepts by means of an example scenario dealing with rescue 
services. In addition, we compare aMCSs to reactive multi-context 
systems and describe how to simulate the latter with our novel ap¬ 
proach. 

1 Introduction 

Research in the field of knowledge representation (KR) has origi¬ 
nated a plethora of different languages and formats. Based on these 
formal concepts a wealth of tools has emerged (e.g., ontologies, 
triple-stores, modal logics, temporal logics, nonmonotonic logics, 
logic programs under nonmonotonic answer set semantics, ...). In a 
“connected world” it is desirable not to spread out information over 
different applications but to have it available for every application if 
need be. Expressing all the knowledge usually represented in specifi¬ 
cally tailored languages in a universal language would be too hard to 
achieve from the point of view of complexity as well as the troubles 
arising from the translation of the representations. Instead, a frame¬ 
work seems desirable that integrates multiple existing formalisms in 
order to represent every piece of knowledge in the language that is 
most appropriate for it. 

Another aspect that has received little attention in the development 
of many KR formalisms is that in a variety of applications, knowl¬ 
edge is provided in a constant flow of information and it is desired 
to reason over this knowledge in a continuous manner. Many for¬ 
malisms are conceptually one-shot formalisms: given a knowledge 
base, the user triggers the computation of a result (e.g., the answer 
to a query). In this paper we aim at using KR formalisms in an on¬ 
line fashion as it has been done in recent works, e.g., on stream data 
processing and querying [111 1 [Tol , stream reasoning with answer set 
programming m. and forgetting ns. 

To address the demand for an integration of heterogeneous knowl¬ 
edge representation formalisms together with the awareness of a 
continuous flow of knowledge over time, reactive multi-context sys- 
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terns (rMCSs) j4j and evolving multi-context systems (eMCSs) f8l 
where proposed. Both frameworks are based on the ideas of man¬ 
aged multi-context systems (mMCSs) 0 which combine multiple 
contexts which can be seen as representations of different formalisms. 
The semantics of rMCSs and eMCSs are based on the notion of an 
equilibrium which realises a tight semantical integration of the differ¬ 
ent context formalisms which is in many applications not necessary. 
Due to reasoning over all contexts, the whole computation is neces¬ 
sarily synchronous as the different contexts have to agree on common 
beliefs for establishing equilibria. 

Many real world applications which utilise communication be¬ 
tween different services use asynchronous communication protocols 
(e.g., web services) and compute as soon as they have appropriate in¬ 
formation about the problem they have to address. Therefore, we in¬ 
troduce asynchronous multi-context systems (aMCSs), a framework 
for loosely coupled knowledge representation formalisms and ser¬ 
vices. It still provides the capabilities to express different knowledge 
representation languages and the translation of information from one 
formalism to another. In addition, aMCSs are also aware of contin¬ 
uous streams of information and provide ways to model the asyn¬ 
chronous exchange of information. To communicate with the envi¬ 
ronment, they utilise input and output streams. 

We will illustrate aMCSs using the example of a task planner for 
medical rescue units. Here, we assume a scenario where persons are 
calling an emergency response team to report incidents and the em¬ 
ployee needs to collect all relevant information about the case. After¬ 
wards, the case needs to be classified and available resources (e.g., 
free ambulances, ...) have to be assigned to the emergencies. In ad¬ 
dition, current traffic data as well as the estimated time of arrival 
should be considered by another employee, the dispatcher. Our pro¬ 
posed aMCS that we understand as a recommender-system for the 
emergency response employee as well as to the dispatcher, incorpo¬ 
rates different contexts like a medical ontology, a database with the 
current state of the ambulances, or a navigation system which is con¬ 
nected to a traffic density reporter. We want to stress that this might 
be one application where it would be a great gain for the overall sys¬ 
tem by allowing asynchronous computation and communication such 
that it is not necessary to wait for all other contexts (e.g., it would be 
unnecessary to wait for the recommendation of a plan of action for 
the dispatcher during the treatment of an emergency call). 

The remainder of this paper is structured as follows. At first we 
will give a short background on concepts we need. In Section [3] we 
extend the basic ideas of MCS to propose our new notion of aMCS 
for modelling asynchronous interaction between coupled knowledge 
representation formalisms and formally characterise its behaviour 
over time. The subsequent section presents an example scenario, 
where asynchronous computation and a reactive response to different 
events is needed. Section [5] compares aMCSs to rMCSs and shows 
how the latter can be simulated by the former. Section [6] concludes 



this paper with a discussion including an outlook on future work. 

2 Preliminaries 

We base our approach on the underlying ideas of mMCSs 0 which 
extend heterogeneous multi-context systems (MCSs) m by a man¬ 
agement layer. It allows for complex updates and revisions of knowl¬ 
edge bases and is realised by a management function that provides 
the updates for each equilibrium. Despite we build on mMCSs, they 
differ substantially in some aspects from the formalism we intro¬ 
duce in this work for reasons intrinsic to the asynchronous approach 
(cf. Section[ 5 ]i. Consequently, we only reuse basic notions from the 
original work and refer the interested reader to the paper of Brewka 
et al. 0 for full details on rnMCS. 

Like rnMCS, aMCSs build on an abstract notion of a logic suite 
which can be seen as an abstraction of different formalisms for knowl¬ 
edge representation. A logic suite is a triple CS = {KB, BS, ACC), 
where KB is the set of admissible knowledge bases (KBs) of CS. 
Each knowledge base is a set of formulas that we do not further spec¬ 
ify. BS is the set of possible belief sets of CS, whose elements are 
beliefs. A semantics for CS is a function ACC : KB —> 2 BS assign¬ 
ing to each KB a set of acceptable belief sets. Using a semantics with 
potentially more than one acceptable belief set allows for modelling 
non-determinism, where each belief set corresponds to an alterna¬ 
tive solution. Finally, ACC is a set of semantics for CS. We denote 
KB,BS, respectively, ACC by KBcs,BScs, respectively, ACCcs- 

The motivation behind having multiple semantics for one formal¬ 
ism is that in our framework, the semantics of a formalism can be 
changed over time. While it is probably rarely the case that one wants 
to switch between different families of semantics during a run, e.g., 
from the stable-model semantics to the well-founded semantics of 
logic programs other switches of semantics are quite natural to many 
applications: we use different semantics to express different reason¬ 
ing modes or to express different queries, i.e., ACCi returns belief 
sets answering a query q\, whereas ACC2 answers query 52; ACC3, 
in turn, could represent the computation of all solutions to a problem, 
whereas at some point in time one could be interested in using ACC4 
that only computes a single solution. For instance one that is optimal 
with respect to some criterion. 

3 Asynchronous Multi-Context Systems 

An aMCS is built up by multiple contexts which are defined next and 
which are used for representing reasoning units. We assume a set JV 
of names that will serve as labels for sensors, contexts, and output 
streams. 

Definition 1 A context is a pair C = (n, CS) where n £ JV is the 
name of the context and CS is a logic suite. 

For a given context C = (n, CS) we denote n and CS by nc and 
CSc, respectively. 

Definition 2 An aMCS {of length n with m output streams) is a pair 
M = (C, 0 ), where C = (Ci,..., C n ) is an n-tuple of contexts and 
0 = (01,..., o m ) with Oj £ JV for each 1 < j < m is a tuple 
containing the names of the output streams of Ad. 

By JV{M) we denote the set {nci,..., n c„ , 01 ,..., o m } of names 
of contexts and output streams of M. 

A context in an aMCS communicates with other contexts and the 
outside world by means of streams of data. In particular, we assume 


that every context has an input stream on which information can 
be written from both external sources (we call them sensors) and 
internal sources (i.e., other contexts). For the data in the communica¬ 
tion streams we assume a communication language XC where every 
i £ XC is an abstract piece of information. In our framework, the 
data in the input stream of a context and the data in output streams 
are modelled by information buffers that are defined in the following. 

Definition 3 A data package is a pair d = {s, I), where s £ JV is 
either a context name or a sensor name, stating the source of d, and 
I C XC is a set of pieces of information. An information buffer is a 
sequence of data packages. 

As we assume that data is asynchronously passed to a context on 
its input stream, it is natural that not all information required for a 
computation is available at all times. Consequently, we need means 
to decide whether a computation should take place, depending on the 
current KB and the data currently available on the stream, or whether 
the context has to wait for more data. In our framework, this decision 
is made by a computation controller as defined next. 

Definition 4 Let C = (n,£<S) be a context. A computation con¬ 
troller for C is a relation cc between a KB KB £ KBcs and a 
finite information buffer. 

Thus, if (KB, ib) £ cc then a computation should take place, 
whereas (KB, ib) V- cc means that further information is required 
before the next computation is triggered in the respective context. 

In contrast to the original definition of multi-context systems (T]| 
and extensions thereof, we do not make use of so-called bridge rules 
as a means to communicate: a bridge rule defines which information 
a context should obtain based on the results of all the contexts of a 
multi-context system. In the asynchronous approach, we do not have 
(synchronised) results of all contexts available in general. As a conse¬ 
quence we use another type of rules, called output rules, that define 
which information should be sent to another context or an output 
stream, based on a result of a single context. 

Definition 5 Let C = (n, CS) be a context. An output rule r for C 
is an expression of the form 

(n, i) <-61,..., bj , not bj+i,... ,not 6 m , (1) 

such that n £ JV is the name of a context or an output stream, i £ XC 
is a piece of information, and every be (1 < i < m) is a belief for C, 
i.e., be £ S for some S £ BScs■ 

We call n the stakeholder of r, (n, i) the head of r denoted by hd(r) 
and 61,..., bj, not bj+i, . .. , not b m the body bd(r) of r. More¬ 
over, we say that r is active under S, denoted by S |= bd(r), if 
{61, ..., bj} C S and {b j+ 1, ..., b m } n 5 = 0 . 

Intuitively, the stakeholder is a reference to the addressee of infor¬ 
mation i. 

Definition 6 Let C = (n, CS) be a context, OR a set of output rules 
for C, S £ BScs a belief set, and n' £ JV a name. Then, the data 
package 

dc{S, OR, n') = (n, {i \ r £ OR, hd(r ) = (n', i), S \= bd(r)}} 
is the output ofC with respect to OR under S relevant for n. 

Compared to previous notions of multi-context systems, contexts 
in our setting only specify which formalisms they use but they do 


not contain knowledge bases, the concrete semantics to use, and 
communication specifications. The reason is that for aMCSs these 
may change over time. Instead, we wrap concepts that are subject to 
change during runtime in the following notion of a configuration. 

Definition? Let C = {n,£>S} be a context. A configuration of 
C is a tuple cf = (KB, ACC, ib, cm), where KB £ ICBcs, 
ACC £ ACCcs, ib is a finite information buffer, and cm is a context 
management for C which is a triple cm = (cc, cu, OR), where 

• cc is a computation controller for C, 

• OR is a set of output rules for C, and 

• cu is a context update function for C which is a function that maps 
an information buffer ib = d \,..., d m and an admissible knowl¬ 
edge base of CS to a configuration cf' = (KB', ACC', ib / , cm') 
ofC with ib' = dk, ■ ■ ■, dm for some k > 1 . 

We write cc cm , cu cm , and OR cm to refer to the components of a 
given context management cm = (cc, cu, OR). The context man¬ 
agement is the counterpart of a management function of an rMCS, 
that computes an update of the knowledge base of a context given 
the results of bridge rules of the context. 

In Section [ 2 ] we already discussed why we want to change se¬ 
mantics over time. Allowing also for changes of output rules can be 
motivated with applications where it should be dynamically decided 
where to direct the output of a context. For example, if a particular 
subproblem can be solved by two contexts C i and C2 and it is known 
that some class of instances can be better solved by C\ and others 
by C2. Then a third context that provides an instance can choose 
whether C\ or C2 should carry out the computation by adapting its 
output rules. Dynamically changing output rules and semantics could 
require adjustments of the other components of the context manage¬ 
ment. Thus, it makes sense that also compution controllers and con¬ 
text update functions are subject to change for the sake of flexibility. 

Definition 8 Let M = ((Ci,..., C n ), (01,..., o m )) be an aMCS. 
A configuration of M is a pair 

Cf = ((cfcf n ), (obi,..., ob m )), 

where 

• for all 1 < i < n cf { = (KB, ACC, ib, cm) is a configuration 
for Ci and for every output rule r £ OR™ we have n £ J\f(M) 
for (n, i) = hd(r), and 

• obj = ..., di- 1, di is an information buffer with a final element 
di that corresponds to the data on the output stream named Oj for 
each 1 < j < m such that for each h < l with dh = (n, i) we 
have n = riCi for some 1 < i < n. 

Figure [T| depicts an aMCS M with three contexts and a configura¬ 
tion for M. 

We next characterise the dynamic behaviour of an aMCS. For eas¬ 
ier notation we stick to a discrete notion of time represented by inte¬ 
gers. 

Definition 9 Let M = ((Ci,..., C n ), (01,..., o m )) be an aMCS. 
A run structure for M is a sequence 

R=...,Cf t ,Cf t+ 1 ,Cf t+2 ,... , 

where t £ Z is a point in time, and every Cf' in R (t' £ Zjua 
configuration of M. 



Figure 1 . An aMCS with three contexts, three sensors on the left side, and 
three output streams on the right side. A solid line represents a flow of in¬ 
formation from a context to its stakeholder streams, whereas a dashed line 
indicates sensor data written to the input buffer of a context. 

We will sometimes use cf \ to denote the configuration of a context 
i that appears at time t in a given run structure in the context of 
a given aMCS. Similarly, ob) refers to the information buffer rep¬ 
resenting the data in the output stream named o j. Moreover, we 
write KB), ACC), ib), and cm) to refer to the components of 
cf\ = (KB, ACC, ib, cm). We say that context Ci is waiting at 
time t if (KB), ib)) 0 cc cm t. 

From run structure to run In aMCSs we take into account 
that the computation of the semantics of a knowledge base needs 
time. Moreover, in a computation of our framework, different belief 
sets may become available at different times and verifying the non¬ 
existence of further belief sets can also take time after the final belief 
set has been computated. In order to model whether a context is busy 
with computing, we introduce a boolean variable busy ) for each con¬ 
figuration cf \ in a run structure. Hence, context Ci is busy at time t 
iff busyl is true. While a context is busy, it does not read new infor¬ 
mation from its input stream until every belief set has been computed 
and it has concluded that no further belief set exists. 

After the computation of a belief set, the output rules are applied 
in order to determine which data is passed on to stakeholder contexts 
or output streams. These are represented by stakeholder buffers : An 
information buffer b is the stakeholder buffer of Ci (for n) at time t 
if 

• b = ib)/ for some 1 < i' < n such that n = n^ is stakeholder of 
some output rule in OR cm t or 

• b = ob y for some 1 < j' < m such that n = Oj/ is stakeholder 
of some output rule in OR cm t. 

In order to indicate that a computation has finished we assume a 
dedicated symbol EOC £ TC that notifies a context’s stakeholder 
buffers about the end of a computation. 

Next, we formally characterise the behaviour of aMCSs followed 
by a summary of its intuition. 

Definition 10 Let M be an aMCS of length n with m output streams 
and R a run structure for M. R is a run for M if the following 
conditions hold for every 1 < i < n and every 1 < j < m: 

(i) if cf* and c/) +1 are defined, Ci is neither busy nor waiting at time 
t, then 

— Ci is busy at time t + 1, 





























- cf\ +1 = cu cm t(ib*,KB*) 

We say that Ci started a computation for KB* +1 at time t + 1. 

(ii) ifCi started a computation for KB at time t then 

- we say that this computation ended at time t', if t' is the ear¬ 
liest time point with t' > t such that (nc^EOC) is added 
to every stakeholder buffer b of Ci at t'; the addition of 
dci(S, OR c t" , n) to b is called an end of computation no¬ 
tification. 

- for all t' > t such that cf\ is defined, Ci is busy at t' unless 
the computation ended at some time t" with t < t" < t'. 

- if the computation ended at time t 1 and cf\ +1 is defined then 
Ci is not busy at t' + 1. 

(iii) if Ci started a computation for KB at time t that ended at time 
t' then for every belief set S E ACC* there is some time t" with 
t <t" < t' such that 

- dci(S, OR c t" , n) is added to every stakeholder buffer b of 
Cifor n at t". 

We say that Ci computed S at time t". The addition of 
dc t {S, OR cmt //. n) to b is called a belief set notification. 

(iv) if ob*' and ob* +1 are defined and obj = then 

ob* +1 = ..., di- 1 , di,..., di> for some l' > l. Moreover, ev¬ 
ery data package din with l < l" < l 1 that was added at time 
t + 1 results from an end of computation notification or a belief 
set notification. 

(v) if cf\ and cf\ +1 are defined, Ci is busy or waiting at time t, and 
ib* = di ,..., di then we have ib* +1 = di ,..., di,..., du for 
some l' > l. Moreover, every data package din with l < l" < l' 
that was added at time t + 1 either results from an end of compu¬ 
tation notification or a belief set notification or n Af(M) (i.e., 
n is a sensor name) for din = (n, i). 

Condition (i) describes the transition from an idle phase to an ongo¬ 
ing computation. The end of such a compation is marked by an end 
of computation notification as introduced in Item (ii). Condition (iii) 
states that between the start and the end of a computation all belief 
sets are computed and stakeholders are notified. Items (iv) and (v) 
express how data is added to an output stream or to an input stream, 
respectively. Note that here, sensors and the flow of information from 
sensors to the input buffers of contexts are implicit. That is, data pack¬ 
ages from a sensor may appear at the end of input buffers at all times 
and the only reference to a particular sensor is its name appearing in 
a data package. 

Summarising the behaviour characterised by a run, whenever a 
context C is not busy, its context controller cc checks whether a new 
computation should take place, based on the knowledge base and 
the current input buffer of C. If yes, the current configuration of the 
context is replaced by a new one, computed by the context update 
function cu of C. Here, the new input buffer has to be a suffix of 
the old one and a new computation for the updated knowledge base 
starts. After an undefined period of time, belief sets are computed 
and based on the application of output rules of C, data packages are 
sent to stakeholder buffers. At some point in time, when all belief 
sets have been computed, an end of computation notification is sent 
to stakeholders, and the context is not busy anymore. 


4 Scenario: Computer-Aided Emergency Team 
Management 

Now we want to consider a scenario, where aMCSs may be used 
to describe the asynchronous information-exchange between dif¬ 
ferent specialised reasoning systems. Our example deals with a 
recommender-system for the coordination and handling of ambu¬ 
lance assignments. The suggested aMCS supports decisions in vari¬ 
ous stages of an emergency case. It gives assistance during the rescue 
call, helps in assigning priorities and rescue units to a case, and as¬ 
sists in the necessary communication among all involved parties. The 
suggestions given by the system are based on different specialised 
systems which react to sensor readings. Moreover, the system can 
tolerate and incorporate overriding solutions proposed by the user 
that it considers non-optimal. 



Figure [2] depicts the example aMCS which models such a 
Computer-Aided Emergency Team Management System (CAET Man¬ 
agement System). Note that interaction with a human (e.g., EM em¬ 
ployee) is modelled as a pair containing an input stream and an output 
stream. The system consists of the following contexts: 

Case Analyser (ca) This context implements a computer-aided call 
handling system which assists an emergency response employee 
(ER employee) during answering an emergency call. The system 
utilises reasoning methods to choose which questions need to 
be asked based on previous answers. In addition, it may check 
whether answers are inconsistent (e.g., amniotic sac bursts when 
the gender is male). For these purposes the case analyser context 
may also consult a medical ontology represented by another con¬ 
text. The communication with the ER employee is represented, on 
the one hand, as a sensor that reads the input of the employee and, 
on the other hand, by an output stream which prints the questions 
and results on a computer screen. 

During the collection of all the important facts for this emergency 
case, the analyser computes the priority of the case and passes it 
to the task planner. 

Med Ontology (mo) This medical ontology can be realised, e.g., 
by a description logic reasoner which handles requests from the 
case analyser and returns more specific knowledge about ongoing 
cases. This information may be used for the prioritisation of the 
importance of a case. 




































Task Planner (tp) This context keeps track of emergency cases. 
Based on the priority and age of a case and the availability and po¬ 
sition of ambulances it suggests an efficient plan of action for the 
ambulances to the (human) case dispatcher (cd). The dispatcher 
may approve some of the suggestions or all of them. If the dis¬ 
patcher has no faith in the given plan of action, she can also alter 
it at will. These decisions are reported back to the planning sys¬ 
tem such that it can react to the alterations and provide further 
suggestions. Based on the final plan, the task planner informs the 
ambulance about their new mission. 

The knowledge base of the context is an answer-set program for 
reasoning about a suggested plan. It gets the availability and posi¬ 
tion of the ambulances by the ambulance manager. In addition, the 
cases with their priority are provided by the case analyser. With 
this information, the task planner gives the locations of the ambu¬ 
lances together with the target locations of the cases to a naviga¬ 
tion system which provides the distances (i.e., the estimated time 
of arrival (ETA)) of all the ambulances to all the locations. 

Amb Manager (am) The ambulance manager is a database, which 
keeps track of the status and location of ambulance units. Each am¬ 
bulance team reports its status (e.g., to be on duty, waiting for new 
mission,...) to the database (modelled by the sensor “Ambulance” 
(amb)). Additionally, the car periodically sends GPS-coordinates 
to the database. These updates will be pushed to the task planner. 
Navigation (na) This part of the aMCS gets traffic information (e.g., 
congestions, roadblocks, construction zones, ...) to predict the 
travel time for each route as accurate as possible. The task planner 
may push a query to the navigation system, which consists of a 
list of locations of ambulance units and a list of locations of target 
areas. Based on all the given information this context will return 
a ranking for each target area, representing the ETAs for each am¬ 
bulance. 

Now we want to have a closer look on the instantiation details of 
some aspects of our example. At first we investigate the cc relation 
of the case analyser. It allows for the computation of new belief sets 
whenever the ER employee pushes new information to the analyser. 
In addition, it will also approve of a new computation if the med¬ 
ical ontology supplies some requested information. Recall that the 
case analyser also assigns a priority to each case and that we want 
to allow the employee to set the priority manually. Let us suppose 
that such a manual override occurs and that the case analyser has an 
ongoing query to the medical ontology. Due to the manual priority as¬ 
signment, the requested information from the ontology is no longer 
needed. Therefore, it would be desirable that cc does not allow for a 
recomputation if all conclusions of the ontology are only related to 
the manually prioritised case. With the same argumentation in mind, 
the context update function cu will also ignore this information on 
the input stream. This kind of behaviour may need knowledge about 
past queries which can be provided by an additional output rule for 
the case analyser which feeds the relevant information back to the 
context. 

Next, we will have a look at the task planner that is based on 
answer-set programming. We will only present parts of the program, 
to show how the mechanics are intended to work. To represent the 
incoming information on the input stream, the following predicates 
can be used: 

case (caseid, loc, priority) represents an active case 
(with its location and priority) which needs to be assigned to an 
ambulance. 

avail (amb, loc) states the location of an available ambulance. 


eta (caseid, amb, value) provides the estimated time of ar¬ 
rival for a unit at the location of the target area of the case, 
assign (amb, caseid) represents the assignment of an ambu¬ 
lance to a case by the dispatcher. 

These predicates will be added by the context update function to 
the knowledge base if corresponding information is put on the input 
stream of the context. Based on this knowledge, the other compo¬ 
nents of the answer-set program will compute the belief sets (e.g., 
via the stable model semantics). Note that an already assigned am¬ 
bulance or case will not be handled as an available ambulance or an 
active case, respectively. In addition, cu can (and should) also man¬ 
age forgetting of no longer needed knowledge. For our scenario it 
may be suitable to remove all eta, avail and case predicates 
when the cases or the unit is assigned. The assign predicate can 
be removed when the ambulance manager reports that the assigned 
ambulance is available again. 

The set OR of output rules of the task planner could contain the 
following rules 0 


(cd,assign(A, C)} <— 
(na,queryA(L)) <— 
(na,queryC(L)) <— 
(amb,assigned(A, C)) t— 


sugassignment(A, C) 
avail(A), not assign(A, _), loc(A, L) 
case(C, P), loc(A, L ), not assign(A, _) 
assign(A, C) 


The first rule informs the case dispatcher (cd) about a suggested as¬ 
signment that has been computed by the answer-set program. Rules 
two and three prepare lists of ambulances and cases for querying the 
navigation context. Recall that the latter needs a list of ambulance 
locations (generated by rule two) and a list of target area locations 
(generated by rule three). Also keep in mind that for each belief set 
a data package with all information for one context or output stream 
is constructed. So the whole list of current target areas and free am¬ 
bulance units will be passed to the navigation context at once. The 
last rule notifies the ambulance team that it has been assigned to a 
specific case. 

Related to this example we want to mention privacy aspects as a 
real world policy which is especially important to applications in pub¬ 
lic services and health care. As the multi-context system is a hetero¬ 
geneous system with different contexts, a completely free exchange 
of data may be against privacy policies. This issue can be addressed 
by the adequate design of output rules, which can also be altered 
with respect to additional information in the input stream (e.g., some 
context gains the permission to receive real names instead of anony¬ 
mous data). So each context may decide by its own which parts of 
the belief sets are shared and exchanged with other contexts. 

Another interesting aspect about aMCSs is the possibility to eas¬ 
ily join two aMCSs together, outsource a subset of contexts in a new 
aMCS, or to view an aMCS as an abstract context for another aMCS 
in a modular way. This can be achieved due to the abstract communi¬ 
cation by means of streams. With respect to our scenario there could 
be some aMCS which does the management of resources for hospi¬ 
tals (e.g., free beds with their capabilities). The task planner might 
communicate with this system to take the needed services for a case 
into account (e.g., intensive care unit) and informs the hospital via 
these streams about incoming patients. It would be easy to join both 
aMCSs together to one big system or to outsource some contexts as 
input sensors paired with an output stream. In addition, one may also 
combine different contexts or a whole aMCS to one abstract context 

3 Keep in mind that in an actual implementation one may want to provide 

further information via communication. 



to provide a dynamic granularity of information about the system and 
to group different reasoning tasks together. 

5 Relation to Reactive Multi-Context Systems 

In this section we want to address differences and communalities 
between aMCSs and rMCSs j4] as both are types of multi-context 
systems that work in an online fashion and can react to external in¬ 
formation. Runs of rMCSs are based on equilibria which are collec¬ 
tions of belief sets—one for each context—on which, intuitively, all 
of the contexts have to agree. Thus, equilibria can be seen as a tight 
integration approach in which the semantics of the individual con¬ 
texts are interdependent. However, the high level of integration also 
comes at the price that the different contexts must wait for each other 
for the computation of each equilibrium, i.e., they are synchronised. 
In aMCSs, on the other hand, the coupling of the semantics is much 
looser—communication between contexts only works via data pack¬ 
ages that are sent to another context after a computation and not via 
a higher-level common semantics for multiple contexts. But as a ben¬ 
efit, each context can ran at its own pace which is useful in settings 
where there is a context that requires much more time for evaluating 
its semantics than others. 

A further difference is the role of non-determinism in the seman¬ 
tics of aMCSs and rMCSs. An equilibrium in an aMCS consists of a 
single belief set for each context. Hence, as aMCSs also use a mul¬ 
tiple belief set semantics, there may also be multiple equilibria as a 
source of non-determinism at each step in a run. For aMCSs, all be¬ 
lief sets of a context are computed in a consecutive way (we assume 
that if only a single belief set is desired than the semantics of the 
respective context should be adapted accordingly by the knowledge 
engineer). Nevertheless, there is also a source of non-determinism in 
the case of aMCSs caused by the undefined duration of computations. 

Regarding the computational complexity of the two frameworks, 
the computation of an equilibrium requires to guess an equilibrium 
candidate first before the semantics of the context is computed which 
is expensive regarding runtime when put to practice. In theory, this 
guess does not add extra complexity if the context semantics is al¬ 
ready NP-hard (as shown in (4]) because it can be combined with 
the guesses required in the contexts. However, this trick cannot be 
used in implementations that uses black boxes for computing context 
semantics. On the other hand, aMCSs do not add substantial compu¬ 
tational requirements to the effort needed for computing context se¬ 
mantics. In particular, aMCSs are scalable as adding a further context 
has no direct influence on how the semantics of the other contexts are 
computed but can only influence the input they get. 

Both, aMCSs and rMCSs are very general frameworks that al¬ 
low for simulating Turing machines and thus for performing multi¬ 
purpose computations even if only very simple context formalisms 
are used (if the length of a run is not restricted). In this sense the 
approaches are equally expressive. Moreover, when allowing for ar¬ 
bitrary contexts one could trivially simulate the other by including 
it as a context. Despite the existence of these straightforward trans¬ 
lations, we next sketch how we simulate an rMCS with an aMCS 
using a more direct translation, as this gives further insight into the 
differences of the two frameworks. Moreover, it demonstrates a way 
to implement rMCSs by means of aMCSs. For every context Ci of a 
given rMCS M r , we introduce three contexts in the aMCS M a that 
simulates M r \ 

• a context C kb that stores the current knowledge base of the con¬ 
text, 


• a context C kb in which a candidate for an updated knowledge 
base can be written and its semantics can be computed, and 

• a management context C™ that implements the bridge rules, and 
the management function of the context. 

There are three further contexts: 

• C obs receives sensor data and distributes it to every context C" n 
where Ci depends on the respective sensor. The context is also 
responsible for synchronisation: for each sensor, new sensor data 
is only passed on after an equilibrium has been computed. 

• C 9U£SS guesses equilibrium candidates for M and passes them to 
the management contexts CJ". Based on that and the information 
from C obs , C™ computes an update kb[ of the knowledge base in 
C kb and stores kb[ in C kb . The latter context then computes the 
semantics of kb[ and passes it to the final context 

• C check that compares every belief set it receives with the equilib¬ 
rium candidate (that it also receives from (J9 uesa y if a matching 
belief set has been found for each context of M r , the candidate is 
an actual equilibrium. In this case C check sends the equilibrium to 
an output stream and notifies the other contexts about the success. 

In case of a success, every context C™ replaces the knowledge base 
in C kb by kbi and a next iteration begins. In case no equilibrium 
was found but one of the C kb contexts has finished its computation, 
Qcheck or( j ers Qguess tQ g Uess ano ther equilibrium candidate. 

6 Related Work and Discussion 

A concept similar to output-rules has been presented in the form of 
reactive bridge rules © . There the flow of information is represented 
by rules which add knowledge to the input streams of other contexts. 
Which information is communicated to other contexts is also deter¬ 
mined by the local belief set of each context. 

Note that evolving multi-context systems |8j follow a quite simi¬ 
lar approach as rMCSs and hence the relation of aMCSs to rMCSs 
sketched in the previous section also applies in essence to this ap¬ 
proach. 

The system dingo (7J is a reactive answer-set programming 
solver. It utilises TCP/IP ports for incoming input streams and does 
also report the resulting answer sets via such a port. It provides means 
to compute different semantics and can keep learned structures and 
knowledge from previous solving steps. Although there are no output 
rules or input stream pre-processing as in aMCSs, the system features 
embedded imperative programming languages which may be helpful 
to model some of the presented concepts of this paper. 

In general, the tasks performed by a context management can be 
realised by different formalisms (e.g., imperative scripting languages 
or declarative programming). Here, it seems likely that different lan¬ 
guages can be the most appropriate management language, depend¬ 
ing on the type of context formalism and the concrete problem do¬ 
main. A feature that is not modelled in our proposal but that is po¬ 
tentially useful and we intend to consider in the future is to allow 
for aborting computations. Moreover, we want to study modelling 
patterns and best practices for aMCSs design for typical application 
settings and compare different inter-context topologies and commu¬ 
nication strategies. 

The next natural step towards an implementation is an analysis 
of how existing tools such as dingo could be used for a real¬ 
isation. It is clear that such formalisms can be used as a context 
formalism. Moreover, we are interested in how reactive features of 


dingo (e.g., iterative computation, on-demand grounding, online- 
queries, ...) relate to aMCS concepts (e.g., cc, ib, ...) and whether 
the system can be described in terms of an aMCS. 
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